Many organizations are embracing the paradigm of Model Based Development in their production processes. “Model Based Development” refers to the practice of specifying, analyzing, and implementing systems using a common “model” consisting of a set of block diagrams and associated objects. System implementation typically consists of automatically generating code for portions of the model, particularly portions corresponding to the system's control algorithm or other functions implemented in software.
Graphical modeling environments are programs that enable a user to construct and analyze a model of a process or system. Examples of graphical modeling formalisms include time-based block diagrams, such as Simulink® from The MathWorks Inc., discrete event diagrams and reactive state machine diagrams, such as those found within Stateflow® also available from The MathWorks, Inc., data-flow diagrams, such as LabVIEW, available from National Instruments Corporation, and software diagrams and other graphical programming environments, such as Unified Modeling Language (UML) diagrams.
Some graphical modeling environments also enable simulation and analysis of models. Simulating a dynamic system in a graphical modeling environment is typically a two-step process. First, a user creates a graphical model, such as a block diagram, of the system to be simulated. A graphical model may be created using a graphical user interface, such as a graphical model editor. The graphical model depicts relationships between the systems inputs, states, parameters and outputs. After creation of the graphical model, the behavior of the dynamic system is simulated using the information entered into the graphical model and information available in its environment such as files and variables in a general purpose workspace. In this step, the graphical model is used to compute and trace the temporal evolution of the outputs of the dynamic systems (“execute the graphical model”). Furthermore, it may automatically produce either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of the model (code generation).
Block diagrams are graphical entities having an “executable meaning” that are created within graphical modeling environments for modeling static and dynamic systems, and generally comprise one or more graphical objects. For example, a block diagram model of a dynamic system is represented schematically as a collection of graphical objects, such as nodes, that are interconnected by edges, generally depicted as lines, which represent relations between the graphical objects that are connected to each of the edges.
In one subset of block diagramming paradigms, the nodes are referred to as “blocks” and drawn using some form of geometric object (e.g., circle, rectangle, etc.). The line segments are often referred to as “signals”. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant when connected to an enabled node. Each node may represent an elemental dynamic system, and the relationships between signals and state variables are defined by sets of equations represented by the nodes. Inherent in the definition of the relationship between the signals and the state variables is the notion of parameters, which are the coefficients of the equations. These equations define a relationship between the input signals, output signals, state, and time, so that each line represents the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another signifies that in terms of computational causality, the output of the first node is an input to the second node. Each distinct input or output on a node is referred to as a port. The source node of a signal writes to the signal at a given time instant when its system equations are solved. The destination node of this signal reads from the signal when their system equations are being solved. Those skilled in the art will recognize that the term “nodes” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
It is worth noting that block diagrams are not exclusively used for representing time-based dynamic systems but also for other models of computation. For example, in Stateflow®, flow charts are block diagrams used to capture behavior of reactive systems and the flow of discrete state changes. Data flow models are block diagrams that describe a graphical programming paradigm where the availability of data is used to initiate the execution of blocks, where a block represents an operation and a line represents execution dependency describing the direction of data flowing between blocks.
In some instances, a user may wish to prevent others from using an element or block without authorization. As such a user may wish to lock access to the functionality of an element such that the locked element may be displayed in the graphical modeling environment but authorization is required in order to execute or simulate using the locked element.
In some instances a user may wish to limit the amount of functionality. In such instances authorization may be required to access the implementation details of a locked element. For example, a user may wish to share an element or a block diagram model with a third party. While the third party may need the element to function as part of a block diagram model, the user may not wish the third party to have access to the implementation details of the element. For example, the user may wish to provide a “black box” block element that can function as part of a block diagram model but does not provide the third party access to underlying functionality or implementation details of the element.